Internet Key Exchange (IKE or IKEv2) is the protocol used to set up a security association (SA) in the IPsec protocol suite. IKE builds upon the Oakley protocol and ISAKMP.[1] IKE uses X.509 certificates for authentication which are either pre-shared or distributed using DNS (preferably with DNSSEC), and a Diffie–Hellman key exchange to set up a shared session secret from which cryptographic keys are derived.[2][3] In addition, a security policy for every peer which will connect must be manually maintained.[2]
Contents |
IKE was originally defined in November 1998 by the Internet Engineering Task Force (IETF) in a series of publications (Request for Comments) known as RFC 2407, RFC 2408, and RFC 2409.
IKE was updated to version two (IKEv2) in December 2005 by RFC 4306.[7] Some open details were clarified in October 2006 by RFC 4718.[8] These two documents plus additional clarifications were combined into the updated IKEv2 RFC 5996[9] which was published in September 2010.
The parent organization of the IETF, The Internet Society (ISOC), has maintained the copyrights of these standards as being freely available to the Internet community.
Most IPsec implementations consist of an IKE daemon that runs in user space and an IPsec stack in the kernel that processes the actual IP packets.
User-space daemons have easy access to mass storage containing configuration information, such as the IPsec endpoint addresses, keys and certificates, as required. Kernel modules, on the other hand, can process packets efficiently and with minimum overhead—which is important for performance reasons.
The IKE protocol uses UDP packets, usually on port 500, and generally requires 4-6 packets with 2-3 turn-around times to create an SA on both sides. The negotiated key material is then given to the IPsec stack. For instance, this could be an AES key, information identifying the IP endpoints and ports that are to be protected, as well as what type of IPsec tunnel has been created. The IPsec stack, in turn, intercepts the relevant IP packets if and where appropriate and performs encryption/decryption as required. Implementations vary on how the interception of the packets is done—for example, some use virtual devices, others take a slice out of the firewall, etc.
IKE consists of two phases: phase 1 and phase 2.[10]
IKE phase 1's purpose is to establish a secure authenticated communication channel by using the Diffie–Hellman key exchange algorithm to generate a shared secret key to encrypt further IKE communications. This negotiation results in one single bi-directional ISAKMP Security Association (SA).[11] The authentication can be performed using either pre-shared key (shared secret), signatures, or public key encryption.[12] Phase 1 operates in either Main Mode or Aggressive Mode. Main Mode protects the identity of the peers; Aggressive Mode does not.[10]
During IKE phase 2, the IKE peers use the secure channel established in Phase 1 to negotiate Security Associations on behalf of other services like IPsec. The negotiation results in a minimum of two unidirectional security associations (one inbound and one outbound).[13] Phase 2 operates only in Quick Mode.[10]
Originally, IKE had numerous configuration options but lacked a general facility for automatic negotiation of a well-known default case that is universally implemented. Consequently, both sides of an IKE had to exactly agree on the type of security association they wanted to create — option by option — or a connection could not be established. Further complications arose from the fact that in many implementations the debug output was difficult to interpret, if there was any debug routine at all.
The IKE specifications were open to a significant degree of interpretation, bordering on design faults (Dead-Peer-Detection being a case in point), giving rise to different IKE implementations not being able to create an agreed-upon security association at all for many combinations of options, however correctly configured they might appear at either end.
The need and intent of an overhaul of the IKE protocol was described in Appendix A of RFC 4306. The following issues were addressed:
This can be explained like this:
Suppose HostA has a Security Parameter Index (SPI) A and HostB has an SPI B.
The scenario is like this:
HostA---------------HostB
If HostB is experiencing large amount of half-open IKE init connection, the responder will send an unencrypted reply message of the ike_sa_init with a notify message of type cookie.And the responder will expect a ike_sa_init request with that cookie value in a notify payload.This is to ensure that the initiator is really capable of handling a response from the responder.
HostA-------------------------------------------------HostB HDR(A,0),sai1,kei,Ni-----------------------------> <----------------------------HDR(A,0),N(cookie) HDR(A,0),N(cookie),sai1,kei,Ni-------------------> <--------------------------HDR(A,B),SAr1,ker,Nr
The IETF ipsecme working group has standardized a number of extensions, with the goal of modernizing the IKEv2 protocol and adapting it better to high volume, production environments. These extensions include:
IKE is supported as part of the IPsec implementation in Windows 2000, Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008.[15] The ISAKMP/IKE implementation was jointly developed by Cisco and Microsoft.[16]
Microsoft Windows 7 and Windows Server 2008 R2 fully support IKEv2 (RFC 4306) as well as MOBIKE (RFC 4555) through the VPN Reconnect feature (also known as Agile VPN).
There are several open source implementations of IPsec with associated IKE capabilities. On Linux, Openswan and strongSwan implementations provide an IKE daemon called pluto, which can configure (i.e., establish SAs) to the KLIPS or NETKEY kernel-based IPsec stacks. NETKEY is the Linux 2.6 kernel's native IPsec implementation.
The Berkeley Software Distributions also have an IPsec implementation and IKE daemon, and most importantly a cryptographic framework (OpenBSD Cryptographic Framework, OCF), which makes supporting cryptographic accelerators much easier. OCF has recently been ported to Linux.
A significant number of network equipment vendors have created their own IKE daemons (and IPsec implementations), or license a stack from one another.
As of May-2006 there are a number of implementations of IKEv2 and some of the companies dealing in IPsec certification and interoperability testing are starting to hold workshops for testing as well as updated certification requirements to deal with IKEv2 testing. ICSA Labs held its latest IKEv2 Interoperability Workshop in Orlando, FL in March 2007 with 13 vendors from around the world.
The following open source implementations of IKEv2 are currently available: